Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-166.txt

Text File | 1992-12-31 | 57KB | 1,499 lines

C.S.M.P. Digest             Thu, 13 Aug 92       Volume 1 : Issue 166

Today's Topics:

    Determining if Color is available
    Distributed and background processing
    MacApp versus TCL



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Dave Martin)
Subject: Determining if Color is available
Organization: Geochemical & Environmental Research Group, Texas A&M University
Date: Tue, 30 Jun 1992 13:03:00 GMT

Hi, guys. Thanks for the helpful answers to my previous novice queries.
Here's another:

My app does not use color *except* within the About... box. That's the
only place -- the DITL has a color PICT resource. In order to improve
the appearance of the About... box when run in monochrome I want to
test the mode and, if the main device is color capable, and using color,
then I put up DLOG 128, otherwise I use DLOG 129. I'm using the device
routines -- GetMainDevice (testing .gdMode) and TestDeviceAttribute. It
works fine on my IIsi/13" RGB in color or mono mode -- the appropriate
dialog comes up based on the setting.
However, I would assume that the device routines do not work on any Mac
which came before the Mac II (those without Color QuickDraw -- the SE,
for instance), and in fact I get an unimplemented trap bomb at the
point that the About... box should be displayed when I run it on an SE.

So, in brief, is there a procedure or function which I can call that will
tell me (even on a pre-color Mac) if color is there? If not, I'll probably
stick with my color About... box -- assuming I can do that even on an SE.

Thanks greatly in advance.

 -                                                                     -
 - Dave Martin - Geochemical & Environmental Research Group, Texas A&M -
 - DAVE@GERGA[GERGO,GERGI].TAMU.EDU - [e-mail] - AOL:DBM -
 -                                                                     -

+++++++++++++++++++++++++++

From: [e-mail] (Anders Wallgren)
Date: 30 Jun 92 17:46:59 GMT
Organization: Verity, Inc., Mountain View, CA, USA

In article <[e-mail]> Dave Martin,
[e-mail] writes:
>So, in brief, is there a procedure or function which I can call
that will
>tell me (even on a pre-color Mac) if color is there? If not, I'll
probably
>stick with my color About... box -- assuming I can do that even on
an SE.

You should use Gestalt to test for the gestaltQuickdrawFeatures -
bit 0 will tell you if Color Quickraw is present.

+++++++++++++++++++++++++++

From: [e-mail] (Dave Martin)
Date: 30 Jun 92 21:58:00 GMT
Organization: Geochemical & Environmental Research Group, Texas A&M University

In article <[e-mail]>, Anders Wallgren <[e-mail]> writes...
>You should use Gestalt to test for the gestaltQuickdrawFeatures -
>bit 0 will tell you if Color Quickraw is present.

Thanks, but Gestalt doesn't work under all Macs (Plus and up) and all Systems
greater than or equal to 6.x, does it? Isn't that a Sys7-specific set of
calls, or am I mistaken there? If I am, then I'll certainly try the Gestalt
routines and see if they do what I need. Thanks.

 -                                                                     -
 - Dave Martin - Geochemical & Environmental Research Group, Texas A&M -
 - DAVE@GERGA[GERGO,GERGI].TAMU.EDU - [e-mail] - AOL:DBM -
 -                                                                     -

+++++++++++++++++++++++++++

From: [e-mail] (Paul Potts)
Organization: Instructional Technology Laboratory, University of Michigan
Date: Thu, 2 Jul 92 12:45:47 GMT

In article <[e-mail]> [e-mail] (Dave Martin) writes:
>In article <[e-mail]>, Anders Wallgren <[e-mail]> writes...
>>You should use Gestalt to test for the gestaltQuickdrawFeatures -
>>bit 0 will tell you if Color Quickraw is present.
>
>Thanks, but Gestalt doesn't work under all Macs (Plus and up) and all Systems
>greater than or equal to 6.x, does it? Isn't that a Sys7-specific set of
>calls, or am I mistaken there? If I am, then I'll certainly try the Gestalt
>routines and see if they do what I need. Thanks.

Yes and no. Yes, the Gestalt trap itself is only in later system version.
No, you don't always need to have that system version to call Gestalt. Recent
versions of both THINK C and MPW will emulate Gestalt in glue if it is not
really available. This means that you can get a decent amount of information
by calling Gestalt even under older systems, and the glue code will use the
older SysEnvirons and whatever else it needs to in order to answer you as best
as it can. If it can't figure it out you'll probably get a result code
returned. For basic things like color I'd say go ahead and use Gestalt and
assume it will work on any machine.
If the call says it doesn't know the answer, assume the functionality isn't
there, I guess.


- --
The essence of OOP: "With all this horse manure, I know there's got to be
                     a pony in here somewhere!"
Paul R. Potts, Software Designer --- [e-mail] <--- me!

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 2 Jul 92 17:53:52 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, Anders Wallgren
<[e-mail]> wrote:
>
> In article <[e-mail]> Dave Martin,
> [e-mail] writes:
> >So, in brief, is there a procedure or function which I can call
> that will
> >tell me (even on a pre-color Mac) if color is there? If not, I'll
> probably
> >stick with my color About... box -- assuming I can do that even on
> an SE.
>
> You should use Gestalt to test for the gestaltQuickdrawFeatures -
> bit 0 will tell you if Color Quickraw is present.

That's a necessary test but not sufficient.  You can have Color QuickDraw
but the screen could be in B&W mode.  To test for the latter, you need to
use the graphic device manager to see how deep the screen really is.

And you can display a color PICT on a Mac SE (unless it's running some
really, really old system).  It may not look very good, however.

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Eric Schlegel)
Date: 02 Jul 92 16:33:55 GMT
Organization: Microsoft Corporation

In article <[e-mail]> Anders Wallgren <[e-mail]> writes:
>In article <[e-mail]> Dave Martin,
>[e-mail] writes:
>>So, in brief, is there a procedure or function which I can call that will
>>tell me (even on a pre-color Mac) if color is there? If not, I'll probably
>>stick with my color About... box -- assuming I can do that even on an SE.
>
>You should use Gestalt to test for the gestaltQuickdrawFeatures -
>bit 0 will tell you if Color Quickraw is present.

No, don't do that - gestaltQuickdrawFeatures is broken, and will always
tell you that Color QD is present, even on a non-CQD machine. I usually
either check for the presence of _OpenCPort or use gestaltQuickdrawVersion.

- -eric
- -------
My opinion, not Microsoft's.


+++++++++++++++++++++++++++

From: [e-mail] (James Preston)
Date: 7 Jul 92 21:04:35 GMT
Organization: Amdahl Corporation, Sunnyvale CA

[e-mail] (Paul Potts) writes:

}No, you don't always need to have that system version to call Gestalt. Recent
}versions of both THINK C and MPW will emulate Gestalt in glue if it is not
}really available.

Can you tell me where this is documented for THINK C?  I have THINK C 5.0
and I looked through the manuals for any mention of this exact issue, and
I could find no mention of it.  So to be safe, I used the "Is Trap Available"
code from Inside Mac VI before calling Gestalt.  But I would like to know
if I can save myself the trouble in the future.

}For basic things like color I'd say go ahead and use Gestalt and
}assume it will work on any machine.

I don't know, call me overly-cautious, but without a definitive answer
to the question of whether your development environment will always generate
the correct glue code, I wouldn't recommend risking having your application
bomb with an unknown trap error.

- --James Preston

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 8 Jul 92 17:54:25 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (James
Preston) writes:
>
> [e-mail] (Paul Potts) writes:
>
> }No, you don't always need to have that system version to call Gestalt. Recent
> }versions of both THINK C and MPW will emulate Gestalt in glue if it is not
> }really available.
>
> Can you tell me where this is documented for THINK C?  I have THINK C 5.0
> and I looked through the manuals for any mention of this exact issue, and
> I could find no mention of it.  So to be safe, I used the "Is Trap Available"
> code from Inside Mac VI before calling Gestalt.  But I would like to know
> if I can save myself the trouble in the future.
>
> }For basic things like color I'd say go ahead and use Gestalt and
> }assume it will work on any machine.
>
> I don't know, call me overly-cautious, but without a definitive answer
> to the question of whether your development environment will always generate
> the correct glue code, I wouldn't recommend risking having your application
> bomb with an unknown trap error.


"OK, you're overly-cautious". You have the information available to you to
determine if you need to check if Gestalt exists or not. Open up your
GestaltEqu.h file. Scroll down to the bottom and you'll see the following:

#if SystemSevenOrLater
#pragma parameter __D0 Gestalt(__D0,__A1)
pascal OSErr Gestalt(OSType selector,long *response)
 = {0xA1AD,0x2288};
#else
pascal OSErr Gestalt(OSType selector,long *response);
#endif


This shows that Gestalt is a library call under the normal case; it is only a
direct call to the trap if you explicitly define SystemSevenOrLater to be
non-zero. Since the only reason for the glue is to see if the Gestalt trap is
implemented and emulate it if not, you can safely avoid checking yourself if you
call the library version of Gestalt.

Note: page 3-33 of IM VI says that MPW 3.2 and later implement Gestalt as glue.
Since THINK C now uses MPW headers and libraries, this comment applies to THINK
C, too.

(Is this in the RTFFAQ yet?)

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 8 Jul 92 10:49:42 GMT

Here's how I decide what to display (pseudocode here because it looks like the
original author has working real code to accomplish DeviceIsDisplayingColor).

err = SysEnvirons( &thisMahcine )
// I think SysEnvirons is present in System 4.2 and higher.
// Glue will allow it to work on all systems under MPW and THINK, though.
if( thisMachine.hasColorQD && DeviceIsDisplayingColor() ) {
    Draw your color pict
} else {
    Draw your b&w pict
}

SysEnvirons seems to work for me.

    - Scott

---------------------------

From: [e-mail] (Michael F. Kamprath)
Subject: Distributed and background processing
Date: 3 Jul 92 13:06:18 GMT
Organization: University of Michigan

I write alot of computational programs, and I always hate it that my computer
is essentially unusable during the computational loops.  I typically
put SystemTask() into each loop so that at least my screen saver will kick in.
I was wondering, how would I write an iterative computational loop such that
my program is "backgroundable" and will still "compute" answers.  Also,
I understand that under system 7, one computer can use "extra" CPU cycles on
on macs on the network.  Is this useful enough to increase computational speed,
and, if so, how would you program it (for floating point type computations)?

Thanks

MIchael Kamprath
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Fri, 3 Jul 1992 15:13:39 GMT

.edu> [e-mail] (Michael F. Kamprath) writes:

   I write alot of computational programs, and I always hate it that my computer
   is essentially unusable during the computational loops.  I typically
   put SystemTask() into each loop so that at least my screen saver will kick in.
   I was wondering, how would I write an iterative computational loop such that
   my program is "backgroundable" and will still "compute" answers.  Also,

Well, you could put all your event handling code into a function
HandleEvent, and do something like:

EventRecord er ;
long l = TickCount ( ) + 3 ;

    for ( i = 0 ; i < 100000 ; i ++ ) {

        for ( j = 0 ; j < 10000 ; j ++ ) {

            q += j + i ;
        }

        if ( TickCount ( ) > l ) {

            if ( WaitNextEvent ( -1 , & er , 0L , NULL ) ) {

                HandleEvent ( & er ) ;
            }
            l = TickCount ( ) + 3 ;
        }
    }


Don't put the idle in the innermost loop. Don't idle unless some
substantial time has passed. If you don't care about window
updating etc, you can omit HandleEvent and pass 0 as first arg
to WaitNextEvent to get a null event back.

   I understand that under system 7, one computer can use "extra" CPU cycles on
   on macs on the network.  Is this useful enough to increase computational speed,
   and, if so, how would you program it (for floating point type computations)?

You'd have to have independent portions of your code (like individual
segments in ray tracing) and use the networking primitives like
AppleEvents or PPC Toolbox - and run the application on both macs,
of course.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

+++++++++++++++++++++++++++

From: [e-mail]
Date: 3 Jul 92 15:05:40 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Michael F. Kamprath) writes:
> I write alot of computational programs, and I always hate it that my computer
> is essentially unusable during the computational loops.  I typically
> put SystemTask() into each loop so that at least my screen saver will kick in.
> I was wondering, how would I write an iterative computational loop such that
> my program is "backgroundable" and will still "compute" answers.

The basic idea is to call "EventAvail" in your loops.  This will allow other
programs to run under MultiFinder just as "GetNextEvent" will.

You don't realy want to call EventAvail every time around your loops otherwise
your computation will crawl.  The best idea is probably to do about
1/60 of a second of computation in between calls to EventAvail by checking
for TickCount to change.

Something like this could be good:

var
   lastTick: longint;

{...}

while ... do begin

   {your stuff}

   if TickCount <> lastTick then begin
      lastTick := TickCount;
      junkBoolean := EventAvail(everyEvent,junkEvent);
   end;

end

For convienience make this a procedure BeNice.
For maximum performance you could check the value of the global variable
Ticks at $16A instead of calling the trap:

var
   TickPtr: ^longint;

TickPtr = Pointer($16A);

if TickPtr^ <> lastTick then ... etc


If even the cost of a single function call is too much then you could use
an inline or (in C) a macro, but that is almost certainly unnecessary.
- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 4 Jul 92 00:28:03 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.gen.nz> [e-mail] writes:

   your computation will crawl.  The best idea is probably to do about
   1/60 of a second of computation in between calls to EventAvail by checking
   for TickCount to change.

I think you actually should hog the CPU more, like 3 or 4 ticks.
(See my previous post) else you will crawl anyway...

   For convienience make this a procedure BeNice.

And lose even more performance. Procedure calls cost, even more
in Pascal than in C. (Preferrably with register arguments)

   For maximum performance you could check the value of the global variable
   Ticks at $16A instead of calling the trap:

NO ! NO ! NO ! Don't use lo-mem globals !

Ticks happen to BREAK under A/UX, and thus will do so under the
MicroKernel, RISC Macs, System 8, System 7.0.2 (OK, maynbe not)
etc...

Call TickCount.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

+++++++++++++++++++++++++++

From: [e-mail]
Date: 4 Jul 92 15:53:56 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
> .gen.nz> [e-mail] writes:
>
>    your computation will crawl.  The best idea is probably to do about
>    1/60 of a second of computation in between calls to EventAvail by checking
>    for TickCount to change.
>
> I think you actually should hog the CPU more, like 3 or 4 ticks.
> (See my previous post) else you will crawl anyway...

Gee, I guess I'm doing everything wrong today.

As it happens, I think 3 or 4 ticks is too much.  One background program
like that would be OK, but three or four would *seriously* impact response
time.

You can get a lot of work done in a tick, and task switches don't take all
that long.


>    For convienience make this a procedure BeNice.
>
> And lose even more performance. Procedure calls cost, even more
> in Pascal than in C. (Preferrably with register arguments)
>
>    For maximum performance you could check the value of the global variable
>    Ticks at $16A instead of calling the trap:
>
> NO ! NO ! NO ! Don't use lo-mem globals !
>
> Ticks happen to BREAK under A/UX, and thus will do so under the
> MicroKernel, RISC Macs, System 8, System 7.0.2 (OK, maynbe not)
> etc...
>
> Call TickCount.


Let's get this straight:  a procedure call is too expensive, but a trap
call is fine?  Yeah, right.

I didn't know that ticks breaks under A/UX (never seen the beast in captivity
myself) but resorting to TickCount is completely unnecessary.  There are
two options:

1) use GetTrapAddress on _TickCount and call it directly.

2) to be even more efficient, forget TickCount entirely and insert your
   own VBL task that increments one of your own global variables.

Either is easy to do.
- --
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"

+++++++++++++++++++++++++++

From: [e-mail] (David E. Sappington)
Date: 5 Jul 92 05:43:16 GMT
Organization: University of Virginia

[e-mail] writes:
> your computation will crawl.  The best idea is probably to do about
> 1/60 of a second of computation in between calls to EventAvail by checking
> for TickCount to change.

[e-mail] (Jon W{tte) replies:
> I think you actually should hog the CPU more, like 3 or 4 ticks.
> (See my previous post) else you will crawl anyway...

[e-mail] replies back:
> As it happens, I think 3 or 4 ticks is too much.  One background program
> like that would be OK, but three or four would *seriously* impact response
> time.

My gut feeling is that, especially on slower CPUs, you should grab
quite a bit more than a tick or two to keep the overhead low.
Furthermore the amount that you grab should vary depending on whether
or not you're the foreground app and (of course!) both foreground and
background values should be user setable.  My defaults are 6/15 in the
background/foreground.  When the user wants to run flat out (and thus
is willingly giving up interaction) he can set the values as high as 99
ticks!

Multiple background apps each grabbing, say, 6 ticks at a pop don't seem
to pound the foreground app too much.  Evidently, the MacOS' scheduler
tries to give time to the foreground app on a regular basis regardless
of the the # of background apps.  Thus the schedule might look something
like <fore> <back 1> <fore> <back 2> <fore> <back 3> ... if the back's
are piggy.

[e-mail] writes:
> You can get a lot of work done in a tick, and task switches don't take all
> that long.

If your app is in the foreground you'll take a noticeable hit (I timed
this once but don't have the #'s with me) and if you're in the background
you'll get CLOBBERED!  Especially with the Sys 7 Finder running.

[e-mail] writes:
> For maximum performance you could check the value of the global variable
> Ticks at $16A instead of calling the trap:

[e-mail] (Jon W{tte) dutifully admonishes:
>  NO ! NO ! NO ! Don't use lo-mem globals ! [the usually reasons why]
> Call TickCount.

[e-mail] replies:
> Let's get this straight:  a procedure call is too expensive, but a trap
> call is fine?  Yeah, right.

I agree completely with Bruce here.  Comparing two variables (a low-mem
and a global) and branching on time outs is so fast that you can put
it in a fairly tight loop and not take much of a hit.  A trap call could
easily overwhelm such a loop.  Still, it's bad karma....

[e-mail] suggests:
> 1) use GetTrapAddress on _TickCount and call it directly.

Not good enough when you have the need for speed!

> 2) to be even more efficient, forget TickCount entirely and insert your
>    own VBL task that increments one of your own global variables.

Now you're talkin'.  This can be even faster than using _Ticks -- just
let the VBL also maintain a boolean global gTimeToYield.  A useful macro
is then

#define BE_NICE  {if (gTimeToYield) CallGNEAndHandleIfNecessary();}

When the branch isn't taken the overhead is nearly nil no matter where
you put the BE_NICEs.

Dave Sappington                     [e-mail]
Institute for Parallel Computation  [e-mail]
University of Virginia

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 5 Jul 92 22:23:48 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.gen.nz> [e-mail] writes:

   You can get a lot of work done in a tick, and task switches don't take all
   that long.

Depends on the machine... You could have it user configurable !
A little slider from "Nice" to "Nasty" :-)

   >    For convienience make this a procedure BeNice.

   > And lose even more performance. Procedure calls cost, even more

   >    Ticks at $16A instead of calling the trap:
   >
   > NO ! NO ! NO ! Don't use lo-mem globals !
   > Ticks happen to BREAK under A/UX, and thus will do so under the

   > Call TickCount.


   Let's get this straight:  a procedure call is too expensive, but a trap
   call is fine?  Yeah, right.

You have a choice between inlining your code and calling a procedure.
Inlining is faster; that's the way I go.

You have a choice between calling TickCount and reading Ticks.
Calling TickCount works, Ticks doesn't. I know the way I'd go,
i.e. THERE IS NO CHOICE !

   I didn't know that ticks breaks under A/UX (never seen the beast in
   captivity myself) but resorting to TickCount is completely unnecessary.
   There are two options:

   1) use GetTrapAddress on _TickCount and call it directly.

Not the best thing to do, since there's been vague warnings about
this for several years.

   2) to be even more efficient, forget TickCount entirely and insert your
      own VBL task that increments one of your own global variables.

Hmm. Maybe. Has some nice advantages, but this is what the Ticks
mechanism already does, so you re-invent the wheel and lose
performance by having the machine do the same thing twice :-)

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

+++++++++++++++++++++++++++

From: [e-mail] (David E. Sappington)
Date: 6 Jul 92 00:55:31 GMT
Organization: University of Virginia

[e-mail] writes:
>   2) to be even more efficient, forget TickCount entirely and insert your
>      own VBL task that increments one of your own global variables.

[e-mail] (Jon W{tte) replies:
> Hmm. Maybe. Has some nice advantages, but this is what the Ticks
> mechanism already does, so you re-invent the wheel and lose
> performance by having the machine do the same thing twice :-)

Yes this is what the Ticks mechanism is supposed to do but if you can't
use the low-memory global _Ticks then what good is it.  The trap's
too slow and bypassing the trap manager to call the TickCount() routine
directly has disadvantages as well.

Dave Sappington                     [e-mail]
Institute for Parallel Computation  [e-mail]
University of Virginia

+++++++++++++++++++++++++++

From: [e-mail] (Marcel Rivard)
Date: 6 Jul 92 00:26:15 GMT
Organization: FORMTEK Inc.

[e-mail] (Michael F. Kamprath)

Michael,


My favorite method of handling this is to use the Threads package out of
Develop 6.
Set up the application with two threads of execution.  One to handle the
UI, and the
second (and others) to handle computation.  Since the threads package is
not pre-emptive,
you need to call "Yield()" every once in a while within each thread to
let other applications
run.

The biggest advantages of this method are that the UI is fully active,
and there is only one
WaitNextEvent() call that handles all events as read events.



Marcel Rivard

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 7 Jul 92 06:41:17 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jon W{tte) writes:

> You have a choice between calling TickCount and reading Ticks.
> Calling TickCount works, Ticks doesn't. I know the way I'd go,
> i.e. THERE IS NO CHOICE !

Is having your code break under A/UX such a big disadvantage? :-)

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 6 Jul 92 13:01:43 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ac.nz> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

[About calling TickCount, not reading Ticks]

   > You have a choice between calling TickCount and reading Ticks.
   > Calling TickCount works, Ticks doesn't. I know the way I'd go,
   > i.e. THERE IS NO CHOICE !

   Is having your code break under A/UX such a big disadvantage? :-)

Yes.

Go ask Alexis Rosen or Jim Jaruselski (hope the names are right)
for instance :-)

Also, A/UX is in many ways a good purgatory for apps that want
to run cleanly on future hardware and software platforms from
apple.


- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

 "Difficult, obscure, incoherent and nonstandard does not imply more power."
               - Andrew Kass in comp.sys.mac.hardware

+++++++++++++++++++++++++++

From: [e-mail] (Jim Jagielski)
Date: 6 Jul 92 13:45:53 GMT
Organization: NASA/Goddard Space Flight Center

[e-mail] (Jon W{tte) writes:


>Go ask Alexis Rosen or Jim Jaruselski (hope the names are right)
                            ----------
                              ^
                              |
                             ack! :)
- --
==============================================================================
#include <std/disclaimer.h>

                Jim Jagielski                  NASA/GSFC, Code 734.4
          [e-mail]             Greenbelt, MD 20771

                     "Squeak. Squeak, I tell you, squeak."

+++++++++++++++++++++++++++

From: [e-mail] (Mark Jefferys)
Date: 9 Jul 92 04:20:55 GMT
Organization: Reed College, Portland, OR

In article <[e-mail]> [e-mail] (David E. Sappington) writes:
%
% [...] if you can't
% use the low-memory global _Ticks then what good is it.  The trap's
% too slow and bypassing the trap manager to call the TickCount() routine
% directly has disadvantages as well.

If the difference between _Ticks and TickCount() is significant then
it's probably being checked too often. TickCount() just doesn't change
often.

It should probably be moved to a higher level of the loop. If the next
level occurs too occasionally then decrement a variable and check
TickCount() every N times.

- --
Mark Jefferys        Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (John Coolidge)
Date: 9 Jul 92 22:09:35 GMT
Organization: A/UX Enabling Technologies - OS Group, Apple Computer, Inc.

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] (Jon W{tte) writes:
>> You have a choice between calling TickCount and reading Ticks.
>> Calling TickCount works, Ticks doesn't. I know the way I'd go,
>> i.e. THERE IS NO CHOICE !

>Is having your code break under A/UX such a big disadvantage? :-)

Having your code break under A/UX is _always_ a big disadvantage :-).
Seriously, things that break under A/UX are much more likely to break
under future releases of the MacOS than things that work under A/UX.
Low memory globals, in particular, should be avoided whenever possible,
since the hypothetical protected memory MacOS would probably dispense
with many if not all of them. If your program is a one-shot,
internal-use-only sort of thing (which I think the original poster was
describing), using Ticks is fine. No commercial product, however,
should ship if it doesn't run under A/UX (excepting hardware-bashers;
they're excused since that's _our_ fault :-)).

Diamonds 1.6 appears to break this rule; it runs fine under A/UX, just
_way too fast_. I suspect Ticks is the problem. We used to have an
option to maintain Ticks in startmac (burned lots of extra time, but it
worked). I think it's gone now. Maybe an INIT that kept up Ticks? Nah...

- --John

        It wasn't lies, Jenny, it was acting.
                -- Nevil Sinclair, _The_Rocketeer_

+++John L. [e-mail]+++++++++++++++++++++++
I speak for myself, not for Apple Computer. Copyright 1992 John L. Coolidge.
Copying allowed only if attributed, and if all copies may be further copied.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 10 Jul 92 17:34:28 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (John Coolidge) writes:
> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
>>Is having your code break under A/UX such a big disadvantage? :-)
>
> Having your code break under A/UX is _always_ a big disadvantage :-).
> Seriously, things that break under A/UX are much more likely to break
> under future releases of the MacOS than things that work under A/UX.

I've heard this argument from Apple people too. I think it's what we used
to refer to politely in my undergraduate days as a "hand-waving" argument.

There's only one case I can think of where A/UX really did presage things to
come in Macintosh: and that was 32-bit addressing. I believe in just about
every other respect, A/UX has actually been *behind* Macintosh in terms of
support for new ways of doing things--32-bit QuickDraw, the new Sound Manager,
System 7 and so on. Remember, these things broke old code, too.

Lawrence "If you want UNIX, get a @$#% UNIX box" D'Oliveiro

+++++++++++++++++++++++++++

From: [e-mail] (Lee Fyock)
Date: 10 Jul 92 19:06:39 GMT
Organization: The MITRE Corporation

OK, let's get back to the "distributed processing across the network"
question.

But first...
I think it would be way cool to have one generic scheduler to execute
tasks on the mac.  A cool thing would be to build it into After Dark.
Like the virex module, I'd like to see disk express, autodoubler and
on location run as modules.  I dislike the fact that each has its
own criteria (and patches!) as to when they should do their thing.

OK.  Given this, it would be awesome to have an after dark module
or other program that would notice the mac is idle, broadcast on
the local net "hey, I'm free" and accept connections to do number
crunching.  The program would accept and run a program and pass
the results back to the caller.  I've heard of something similar
for the NeXT (called godzilla?), and several rendering packages
on the mac are implementing something similar, but a generic
capability would be extraordinarily useful.

You guys can kick around the p-code vs. assembly and other issues
for a while...  :-)


Have fun!

Lee Fyock
[e-mail]

---------------------------

From: [e-mail] (Domingo A. Mihovilovic)
Subject: MacApp versus TCL
Organization: Computer Science Department, Stanford University.
Date: Mon, 6 Jul 1992 07:09:11 GMT

    I am trying to define my programming environment to produce
a hopefully commercial application.

    I got Think Pascal and Think C. I have been learning about
the Think Class libraries and they look very good (I used to
do everything from scratch, but I will not do it anymore...).

    Is there any good reason why I should consider using
MacApp as my set of classes ? or MPW as my development environment ?

    Any idea if there is any "Think C++" under development ?
(standard C++)

    Thanks for any information,

Domingo Mihovilovic
[e-mail]



+++++++++++++++++++++++++++

From: [e-mail] (Chuck McMath)
Date: 6 Jul 92 18:24:27 GMT
Organization: MSD

In article <[e-mail]>,
[e-mail] (Domingo A. Mihovilovic) wrote:
>
>
>     I am trying to define my programming environment to produce
> a hopefully commercial application.
>
>     I got Think Pascal and Think C. I have been learning about
> the Think Class libraries and they look very good (I used to
> do everything from scratch, but I will not do it anymore...).
>
>     Is there any good reason why I should consider using
> MacApp as my set of classes ? or MPW as my development environment ?
>
>     Any idea if there is any "Think C++" under development ?
> (standard C++)
>
>     Thanks for any information,
>
> Domingo Mihovilovic
> [e-mail]

Well, if you already have ThinkC & TCL that's a pretty strong argument to
not switch into MPW.  Buying into MacApp & MPW is a pretty hefty amount,
especially since you need 1. MPW Shell 2. C Compiler 3. C++ preprocessor 4.
MacApp 5. Assembler (for parts of MacApp).  Hmm, I think that's it.  Heck,
just buy ETO (that's a quarterly CD-ROM from Apple that contains ALL of
their developement tools on it, everything listed above plus Pascal,
ResEdit, code snippets, etc, etc, etc). Oh yeah, one small problem - ETO
costs $1000 if you don't own any of the abovementioned stuff.

Of course, this doesn't address the differences between TCL and MacApp, and
which is better for what purpose.  That's a pretty deep subject.  Suffice
to say that you can produce good software with TCL and with MacApp.  MacApp
puts you farther down the road (the dialog classes are excellent) but it
costs a whole lot more in terms of $$$ and machine requirements.  If you
have the bucks and a Mac IIx or better with at least 8 MB of RAM and a 150
MB Hard disk, and a CD-ROM player, then maybe MPW/MacApp is the way to go.
But it has a pretty steep learning curve.  However, once you get over that
curve, your programs are quite nice!

Symantec has said that when and if they come out with C++ it will be a
separate product from ThinkC, so don't look for ThinkC to become ThinkC++
anytime soon.

chuck

|- chuck mcmath - [e-mail] - MSD, Inc. ------------|
|- National Library of Medicine - National Institutes of Health --|
|- Bethesda, MD 20894 ---- Spell(e)s better than Dan Quayle ------|
|- "Hey batter, hey batter, hey batter, swing" - Anon. -----------|

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Organization: Taligent, Inc.
Date: Mon, 6 Jul 1992 20:42:39 GMT

In article <[e-mail]>,
[e-mail] (Chuck McMath) wrote:
>
> especially since you need 1. MPW Shell 2. C Compiler 3. C++ preprocessor 4.
> MacApp 5. Assembler (for parts of MacApp).  Hmm, I think that's it.  Heck,

You don't need an assembler unless you intend to rebuild MacApp from
scratch.  (Even then, I'm not sure it's needed.)  MacApp should come with
the assembler files already processed.

Also, you can use MacApp from MPW Object Pascal.  (Or if you have THINK
Pascal, you may be able to get MacApp 2.x and use MacApp from THINK
Pascal.)

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

Organization: Queen's University at Kingston
Date: Monday, 6 Jul 1992 20:54:18 EDT
From: <[e-mail]>

1)  Whether you choose TCL or MacApp, consider buying AppMaker from Bowers
    Development.  It is a very handy tool for building the interface, builds
    decent code for Pascal, C, Object Pascal, TCL, MacApp, and it's mild to
    your hands.

2)  Larry Rosenstein modestly doesn't mention that there is a good book on
    MacApp (2.x) that he co-authored.  I don't know if there will be "update"
    to it (it is "Programming with MacApp" by David A Wilson, Larry S. Rosen-
    stein, and Dan Shafer  ISBN 0-201-09784-2  Addison Wesley Publishing).
    Although MacApp 2.x isn't the current version (unless you got caught
    using Pascal for your project), I believe most of the concepts will travel
    well.  (I haven't used the new version of MacApp.)

    I know that there is at least one TCL book in the works (and it is needed
    even though I think TCL is simpler) but whose to say when or if it will
    be available.

    Best wishes.  Once you start using an object-oriented language, you'll
    never want to go back...

.../dave   David Charlesworth

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Jul 92 02:20:14 GMT
Organization: Apple Inc, Debugging Department

In article <[e-mail]>, [e-mail] (Larry
Rosenstein) wrote:
> You don't need an assembler unless you intend to rebuild MacApp from
> scratch.  (Even then, I'm not sure it's needed.)  MacApp should come with
> the assembler files already processed.

Nearly true (I feel like a bandit correcting one of the founding designers
of MacApp...). We have a couple of asm files in the MacApp 3.0 library,
FloatWindow.a (with the floating window WDEF), UFailure.a, UMemory.a and
UPascalObject.a. Anyway the CD distributions have most possible library
configurations, however there's always a small chance that the developer
wants a library version not available on the CD.


Also, if you need to patch the sources 1) then asm is handy. The third
point
is if someone wants to modify the WDEFs for their own liking, one could
write
C code but asm is far more efficient.

Cheers,
Kent/DTS


1) From additional DTS release notes concerning the future MacApp 3.0.1:
There is a problem that can prevent successfull linking when specifying a
- -modelfar build. The problem is evident in the InitLinkerSymbols PROC in
UPascalObject.a. It contains A5-relative references to SUPERCLASSTABLE,
CLASSTABLE, and SELECTORPROCTABLE such as

LEA %_SUPERCLASSTABLE, A0

which are later patched like this

LEA *+xxxx,A0

If any of these modules fall farther than 32K away from the
InitLinkerSymbols instructions that reference them, a linker error will
occur. If this happens the linker error output might appear something like
this:

  ### While reading file
"avatar:MPW:MacApp:Libraries:.DebugSymFar:MacApp.lib"
  ### Link: INITLINKERSYMBOLS (32712)
  Reference to: %_SELECTORPROCTABLE in file:
  ### Link: Error: PC-relative edit, offset out of range. (Error 48)
  INITLINKERSYMBOLS (32712)
  Reference to: %_CLASSTABLE in file:
  ### Link: Error: PC-relative edit, offset out of range. (Error 48)
INITLINKERSYMBOLS (32712)
  Reference to: INITLINKERSYMBOLS in file: ### Link: Error: PC-relative
edit,
offset out of range. (Error 48) INITLINKERSYMBOLS (32712)



The following 3 changes to the UPascalObject.a file in the
MacApp:Libraries: folder fix this problem.

In the definition of PROC InitLinkerSymbols, find the line
     If qModelFarCode then

Following this line are 3 "LEA" instructions and 3 "MOVE.L" instructions.
By changing the form of the LEA instructions, they can be changed into
- -model far references, and avoid the 32K limit.  Make the following 3
changes...

   lea %_SUPERCLASSTABLE(A5),A0
becomes
   lea (%_SUPERCLASSTABLE).L,A0

   lea %_CLASSTABLE(A5),A0
becomes
   lea (%_CLASSTABLE).L,A0

and

   lea %_SELECTORPROCTABLE(A5),A0
becomes
   lea (%_SELECTORPROCTABLE).L,A0

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Wed, 8 Jul 92 12:38:49 EST
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Domingo A. Mihovilovic) writes:

>    Is there any good reason why I should consider using
>MacApp as my set of classes ? or MPW as my development environment ?

Just to muddy the waters, you might want to check out the announcement
about bedrock.  To put it succinctly, MacApp is dead, Symantec is
writing Bedrock, a cross platform object development environment,
apple is loaning its MacApp engineering team to Symantec.  I don't
know how this will affect TCL.  Nobody seems to know what kind of
distribution will be available (e.g. if the Source will be with us
:-) ), nor does anyone really know about upgrades.

At present, it looks like the people who listened to Apple's
preaching that MacApp was it will be taking it on the chin.

MPW's strength is for large, multi-person, multi-project development
efforts.  Think is great if you are doing a one person-one project
effort.

Think tends to bite it when new systems/platforms come out, where
as MPW tends to react a bit faster.

Think does not do C++ as yet.

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Annon:    [e-mail]
"Reporter : Mr Gandhi, what do you think of Western Civilization ?
Gandhi : I think it would be a good idea."

+++++++++++++++++++++++++++

From: [e-mail] (Chuck McMath)
Date: 9 Jul 92 11:28:26 GMT
Organization: MSD

In article <[e-mail]>, [e-mail]
(Cory Kempf) wrote:
>
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Domingo A. Mihovilovic) writes:
>
> >    Is there any good reason why I should consider using
> >MacApp as my set of classes ? or MPW as my development environment ?
>
> Just to muddy the waters, you might want to check out the announcement
> about bedrock.  To put it succinctly, MacApp is dead, Symantec is
> writing Bedrock, a cross platform object development environment,
> apple is loaning its MacApp engineering team to Symantec.  I don't
> know how this will affect TCL.  Nobody seems to know what kind of
> distribution will be available (e.g. if the Source will be with us
> :-) ), nor does anyone really know about upgrades.
>
> At present, it looks like the people who listened to Apple's
> preaching that MacApp was it will be taking it on the chin.
>

I think the above statements are way overblown.  Everything Apple has been
saying is that the *kinds* of things you learn by programming in MacApp are
going to transfer to Bedrock.  Sure, class names and some designs will be
different, and there will be new ground to conquer, but if you think you
will be at some sort of advantage by *waiting* then you are quite naive.

There's a lot to grasp when using object oriented frameworks and oo
programming.  You can learn it by using MacApp or by using TCL.  But IMHO,
using MacApp will prepare you better for a move to Bedrock.

If MacApp is dead, there are an awfully lot of people using a dead system.
And the alternative is... what? TCL?  If MacApp is dead, then TCL is
buried.  I never could get into using a system what had a class called
TBartender...

Another thing - if you think there will be a stable, commercial-grade
version of Bedrock next January, I have some swampland in Florida to sell
you!  Apple has done a good job recently of getting stuff out to developers
(on ETO, for example), but projects of this magnitude take time, and
usually one good release, before you can count on the framework being
stable.  MacApp had a lot of development time and effort put into it, and
its structure changed radically between version 1.0 -> 2.0, and also
between 2.0 -> 3.0.  So again, you don't really gain anything by saying
"I'll wait for Bedrock."

Of course all of this above discussion is without regard to cost.  If
that's a factor, then maybe you would rank TCl and MacApp differently,
since it takes quite a chunk to get a platform suitable for MacApp
development.

> MPW's strength is for large, multi-person, multi-project development
> efforts.  Think is great if you are doing a one person-one project
> effort.

Of course, MPW is also good when you are mixing Pascal, C, and Assembler,
or when you are using MacApp (duh).  And the fact that MPW has scripts,
source code control, grep (for files NOT in the current project!), and lots
of other neat utilities is a plus.  I have seen MPW used for single-person
projects (that's how I use it now) and ThinkC used for multi-person
projects.  They all work, it just depends on the amount of fiddling around
you want to do.

>
> Think tends to bite it when new systems/platforms come out, where
> as MPW tends to react a bit faster.
>

Apple has sort of an advantage here, since they make the new hardware...

> Think does not do C++ as yet.
>

>From what I've heard, ThinkC will never do C++.  Symantec has said that
when and if they do a C++ under their name, it will be a new product.

> +C
>
>
> -------------------------------------------------------------
> Cory Kempf                    EnigamI, Inc.
> [e-mail]           ...!decvax!enigami!cory
> Annon:    [e-mail]
> "Reporter : Mr Gandhi, what do you think of Western Civilization ?
> Gandhi : I think it would be a good idea."


chuck


|- chuck mcmath - [e-mail] - MSD, Inc. ------------|
|- National Library of Medicine - National Institutes of Health --|
|- Bethesda, MD 20894 ---- Spell(e)s better than Dan Quayle ------|
|- "Hey batter, hey batter, hey batter, swing" - Anon. -----------|

+++++++++++++++++++++++++++

From: [e-mail] (Cory Kempf)
Date: Thu, 9 Jul 92 23:58:35 EST
Organization: EnigamI, Inc., Nashua, NH


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Chuck McMath) writes:
>In article <[e-mail]>, [e-mail]
>(Cory Kempf) wrote:

>> At present, it looks like the people who listened to Apple's
>> preaching that MacApp was it will be taking it on the chin.

>I think the above statements are way overblown.  Everything Apple has been
>saying is that the *kinds* of things you learn by programming in MacApp are
>going to transfer to Bedrock.

Yes, I am sure that the *idea* of programming within a framework will
transfere.  Personally, I think that this is rather insignificant
though, especially when one considered the learning curve of for MacApp
itself.

>                          Sure, class names and some designs will be
>different, and there will be new ground to conquer, but if you think you
>will be at some sort of advantage by *waiting* then you are quite naive.

I don't think that there is any *advantage* to waiting.  What it looks
like (BTW, if anyone who *knows* is allowed to speak, please feel
free to correct me) is that the time & effort involved in learning MacApp
(very expensive!) would be wasted (e.g. learning things like MacApp
has a TFileBasedDocument, and how MacApp has wired it up, and how
it relates to Files, Documents, Views, etc under MacApp, the methods
to call, the names of the classes to call, etc).

>There's a lot to grasp when using object oriented frameworks and oo
>programming.  You can learn it by using MacApp or by using TCL.  But IMHO,
>using MacApp will prepare you better for a move to Bedrock.

I don't debate this.  What I do question is that for someone who does
not yet know MacApp, but does understand object programming, is it
worth the price to learn MacApp?  Given that it will be going poof
in the near future?

>If MacApp is dead, there are an awfully lot of people using a dead system.

Apple has announced that MacApp is going to be replaced by Bedrock.
Unfortunately, nothing further about Bedrock, or the migration path
is known at present.

>Another thing - if you think there will be a stable, commercial-grade
>version of Bedrock next January, I have some swampland in Florida to sell
>you!

I don't believe it either.  What I do believe is that the MacApp team
is not working on developing a newer, better version of MacApp, nor
are they working on the promised cross-platform versions.  The release
date for bedrock (actual or announced) does not change this.

>Of course all of this above discussion is without regard to cost.  If
>that's a factor, then maybe you would rank TCl and MacApp differently,
>since it takes quite a chunk to get a platform suitable for MacApp
>development.

The major cost as *I* see it is the learning time.  For MacApp, this
is very expensive.  Since MacApp is slated to be orphaned, this means
that this learning time will not have a long term payoff.  At present,
it is unknown how similar the structure of Bedrock will be w.r.t.
MacApp.  E.g., how much of that learning curve time is wasted.

So, back to my original question: given the announced end of MacApp
future development, does it make sense to continue trying to learn
MacApp?

+C


- -------------------------------------------------------------
Cory Kempf                    EnigamI, Inc.
[e-mail]           ...!decvax!enigami!cory
Annon:    [e-mail]

"F' cryin' out loud, it's *your* life; shouldn't you at least examine
your lifestyle values to see if they are really what *you* want."
                                        --Keith Lim

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 10 Jul 92 16:59:08 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail]
(Cory Kempf) wrote:
>
> Yes, I am sure that the *idea* of programming within a framework will
> transfere.  Personally, I think that this is rather insignificant

I don't think it's insignificant for the typical programmer (who has no
exposure to object-oriented programming).

> though, especially when one considered the learning curve of for MacApp
> itself.

It also depends on the person's current experience.  If they are pretty
familiar with programming the Macintosh, then it may not bve worthwhile
learning MacApp.  (That may be true regardless of MacApp's status.)

If they are not familiar with programming the Macintosh, then it's probably
easier to go the MacApp or TCL route than trying to read Inside Mac.

> free to correct me) is that the time & effort involved in learning MacApp
> (very expensive!) would be wasted (e.g. learning things like MacApp

It's not clear at the time if it will be a total waste or not.  I suspect
that most of the same concepts will carry over.  There are several general
concepts in MacApp (change propagation, behaviors, etc.) that may be useful
to learn about.

At last night's BAMADA meeting, one of the people involved estimated that
the transition from MacApp 3.0 to Bedrock would be roughly equivalent to
the transition from MacApp 2.0 to 3.0.

> not yet know MacApp, but does understand object programming, is it
> worth the price to learn MacApp?  Given that it will be going poof

If someone is already familiar with object programming and frameworks, then
probably not.  They should just stick with whatever they're using.  But I
would give the same advice even if there was no Bedrock.

> >Another thing - if you think there will be a stable, commercial-grade
> >version of Bedrock next January, I have some swampland in Florida to sell
>
> I don't believe it either.  What I do believe is that the MacApp team
> is not working on developing a newer, better version of MacApp, nor
> are they working on the promised cross-platform versions.  The release

Well the fact is that Symantec has been working on Bedrock for over 2
years, so it's not as if they are starting from scratch.  Apparently, most
of the effort between now and the ship date involves adding some of the
features that MacApp 3.0 has and improving the documentation to the point
where it can be a commercial product.  (There's a difference between a tool
used internally and one that you sell to others.)

I'm not sure what you're referring to above, but members of the MacApp team
are working at Symantec on Bedrock.

> So, back to my original question: given the announced end of MacApp
> future development, does it make sense to continue trying to learn
> MacApp?

It depends on the person.  If you already are using TCL, then it doesn't
make sense.  If you've never used any kind of framework then MacApp is a
reasonable alternative.  (Especially, if you want to ship your product in
the next year or so.)

Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 10 Jul 92 17:03:19 GMT
Organization: Taligent, Inc.

In article <[e-mail]>,
[e-mail] wrote:
>
> 2)  Larry Rosenstein modestly doesn't mention that there is a good book on
>     MacApp (2.x) that he co-authored.  I don't know if there will be "update"

As far as I know there's no update planned.  We aren't working on one, and
although there's been rumors of other's picking it up, I don't think it
will happen.

Larry Rosenstein
Taligent, Inc.

[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************